Applications login using a mechanism relating sub-tokens to the quality of a master token

ABSTRACT

Methods and systems allow a user to log in to a device so that a number of apps become accessible on the device without the user repeatedly logging in to each different app as the user launches multiple apps. A mechanism of providing a master token with a quality score and providing sub-tokens for each app that can use the sub-token and the score quality to evaluate the level of security provided by the initial login allows each app to skip its own login process and provides a level of enhanced efficiency and convenience for the user. A method includes authenticating a user; creating a master token on the user device; creating a sub-token of the master token for an app launched on the device; the app skipping the login process of the app in response to the sub-token so that the app proceeds directly to validating a transaction.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of, and claims the benefit ofpriority of, co-pending U.S. patent application Ser. No. 14/178,716,filed Feb. 12, 2014, issued Aug. 18, 2015 as U.S. Pat. No. 9,111,083which is a continuation of U.S. patent application Ser. No. 13/340,521,filed Dec. 29, 2011, issued Apr. 1, 2014 as U.S. Pat. No. 8,689,310,each of which is incorporated by reference herein in its entirety.

BACKGROUND

1. Technical Field

The present disclosure generally relates to security for communicationsconducted over a network using a handheld mobile or other consumerelectronic device and, more particularly, to a security mechanism forlogging in to apps executing on the device that provides userconvenience through either fast login or avoiding repetitive logging inwhen using multiple apps on the device.

2. Related Art

Many compact, handheld consumer electronic devices such as mobile phoneswith mobile web browsers, smart phones, and electronic note pads allowthe use of various applications programs, or “apps”, for a great varietyof types of communications including, for example, texting, socialnetworking, email, and electronic commerce, which generally refers tothe buying and selling of products or services over electronic networkssuch as the Internet and other computer networks using electronicdevices. Apps used for these various types of communication may benefitfrom and even rely on some form of security in terms of not allowingunauthorized access to use of the app, and thus may require some form oflogin. For example, a bank or other financial service provider mayprovide an app for use on a mobile device that allows access to thedevice user's account at the financial service provider, Similarly, inthe case of email and social networking, for example, it can bedesirable and important to prevent impersonation of the owner of theemail account or the owner's social networking page. Thus, many of theapps on a user's device may require some form of secure login toauthenticate the user of the app. When many apps are being used at onetime on a single device, the user may encounter some inconvenience(e.g., delay in accomplishing desired tasks) from multiple or repetitivelogins when switching from one app to another or when returning to apreviously used app that has already logged the user out.

SUMMARY

According to one or more embodiments of the present invention, methodsand systems are provided for allowing a user to log in to a device insuch a way that a number of apps become accessible on the device withoutthe user having to repeatedly log in to each different app as the userlaunches multiple apps. A mechanism is disclosed of providing a mastertoken with a quality score and providing sub-tokens for each app thatcan use the sub-token and the score quality to evaluate the level ofsecurity provided by the initial login, allowing the app to shorten orskip its own login process and providing a level of enhanced efficiencyand convenience for the user.

In one or more embodiments, a system includes a processor and acomputer-readable medium having computer readable code for instructingthe processor to perform a method, the method comprising: authenticatinga user via a user device communicating over a network with a serviceprovider; creating a master token on the user device; checking if themaster token is present on the device; creating a sub-token of themaster token for an app on the device launched by the user; launchingthe app includes jumping over the login process by the app in responseto the sub-token so that the app proceeds directly to validating atransaction; and validating the transaction based on informationincluded in the sub-token.

These and other aspects of the present disclosure will be more readilyapparent from the detailed description of the embodiments set forthbelow taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a system diagram illustrating a system for score based fastlogin using sub-tokens for login to multiple apps and communicating overa network in accordance with one or more embodiments;

FIG. 2 is a block diagram illustrating a mechanism for score based fastlogin using sub-tokens for login to multiple apps and communicating overa network in accordance with one or more embodiments; and

FIG. 3 is a process flow diagram illustrating a method for score basedfast login using sub-tokens for login to multiple apps and communicatingover a network in accordance with one or more embodiments.

Embodiments of the invention and their advantages are best understood byreferring to the detailed description that follows.

DETAILED DESCRIPTION

According to one or more embodiments of the present invention, methodsand systems are provided for securely logging in to a device andcommunicating over a network in such a way that login to the deviceprovides authentication that can be used to facilitate subsequent logins(e.g., to one or more apps) that can significantly improve the userexperience. In other words, a secure device binding may provide userconvenience through avoiding repetitive logging in when changing apps(application programs). In one embodiment, a user and a device may bestrongly authenticated at an initial login, e.g., using biometrictechnology. As a result of the strong authentication, a temporary mastertoken may be generated that other applications can leverage by the useof sub-tokens to provide log in security to the app without the apprequiring its own login from the user. Thus, the user may be allowed tolog in to a device in such a way that a number of apps become accessibleon the device without the user having to repeatedly log in to eachdifferent app as the user launches multiple apps. Avoiding multiplelogins or even login for just one app, according to some embodiments,may allow reducing time latency when checking out from online shopping,service provider payments at a point-of-sale (POS), and also may helpsolve off-the-grid transactions. In one embodiment, biometrics may,thus, be used not so much only to “secure” the user but also to providethe user time saving convenience.

In one or more embodiments, a mechanism is disclosed of providing amaster token with a quality score and providing sub-tokens for one ormore apps (e.g., each app has its own sub-token) that can use thesub-token and the score quality to evaluate the level of securityprovided by the initial login, allowing the app to securely shorten orskip its own login process and providing a level of enhanced efficiencyand convenience for the user. In one embodiment, the same app whichgenerates the master token may also generate the sub-token for any otherapp, interfacing with the app via an application programming interface(API.) of the app. In another embodiment, each app may generate its ownsub-token, accessing the master token via an API. In one embodiment, themaster token may be a root token of a tree (data structure) of tokensincluding the sub-tokens linked to the root token.

As a result, when the user accesses one or more apps on the mobiledevice, there may be no need to go through a login process in the app. Alogin may nevertheless be required in certain situations, such as a highdollar amount purchase, based on risk parameters pre-determined by theservice provider.

In one embodiment, a mobile device is bound, or undergoes binding, to anaccount—for example, with a service provider, merchant, bank, or othercommercial entity—to enable a security features of apps on the device sothat customers do not always have to enter their password when goingthrough a shopping checkout or other financial transaction process withan app on a known mobile device. This device binding can serve as thebasis for functionality such as skipping redundant login in variouspayment flows, risk management processes and models, and otherdevice-based logic. In one embodiment, a device may be bound during aninitial login, for example, through device interrogation to get a deviceidentification (ID) which may include one or more device identifiers.

Device binding may be based on biometric technology (e.g., finger printswipe, retinal scan, voiceprint) and, either alternatively or inaddition, on a unique device identifier which is present on the device(e.g., international mobile equipment (IMEI) number, name of device,various date modified checks (e.g., a firmware new version with adifferent time stamp from the previously installed version), and othervariables, or a combination of identifiers). Use of such a device-uniqueidentifier may enable the service provider to remember a user acrossapps on a device if the user wants to skip subsequent logins on thedevice. Multiple mobile devices may be bound to a single account.

FIG. 1 illustrates a system 100, in accordance with one or moreembodiments, for score based fast login using sub-tokens for login tomultiple apps and making a payment (or other financial transactionneeding security) by a user 102 using a mobile device 104 (also referredto as “user device”) to communicate over a network 106 (e.g., theInternet) to a commercial entity (e.g., merchant 130) using a serviceprovider (SP) 120. The service provider 120 may be a payment provider orother provider of financial services, such as PayPal, Inc. of San Jose,CA. Network 106 may be implemented as a single network or a combinationof multiple networks. For example, in various embodiments, network 106may include one or more intranets, landline networks, wireless networks,or other appropriate types of communication networks including theInternet. In another example, the network may comprise a wirelesstelecommunications network (e.g., cellular phone network) adapted tocommunicate with other communication networks such as the Internet.

Mobile device 104 may be, for example, a laptop, smart phone, tablet, orother mobile computing or communication devices, televisions withinternet connection, set-top boxes or other network-connected devices.Mobile device 104, which may function as a client (and may also bereferred to as “client device” 104) may be implemented using anyappropriate combination of hardware and software configured for wired orwireless communication over network 106. For example, mobile device 104may be implemented as a personal computer of user 102 (e.g., a client orcustomer) in communication with network 106. Also for example, mobiledevice 104 may be implemented as a wireless telephone (e.g., cellphone), personal digital assistant (PDA), or notebook computer.

As seen in FIG. 1, a browser app 108 may run on mobile device 104 andmay be used to provide a user interface to permit user 102 to browseinformation available over network 106. For example, browser app 108 maybe implemented as a web browser to view information available overnetwork 106. In one implementation, browser app 108 may comprise asoftware program such as a graphical user interface (GUI) executable bya processor that is configured to interface and communicate withmerchant 130 and service provider 120 via network 106. For example, user102 may access merchant websites via merchant 130 to find and purchaseitems. User 102, through client mobile device 104, may also communicatewith service provider server 122 to create an account and make a paymentto the merchant 130 via service provider 120. Mobile device 104 mayinclude other apps 110 as may be desired to make additional featuresavailable to user 102, including making quick payments with serviceprovider server 122. For example, apps 110 may include interfaces andcommunication protocols that allow the user 102 to receive and transmitinformation through online sites via network 106. Apps 110 may alsoinclude security applications for implementing client-side securityfeatures, programmatic client applications for interfacing withappropriate application programming interfaces (APIs) over network 106and various other types of generally known programs and applications.

Mobile device 104 may also include applications 112, 114 for enrollmentand authentication of the user. For example, application 112 may providefor establishing an account and a secure identity with service provider120. Application 112 may, for example, establish a biometric identityfor the user 102 that connects user 102 with device 104 so that when theuser swipes his finger across a fingerprint reader (for example) on thedevice, the user's fingerprint is established as an ID for the device104 and as an ID for an account with service provider 120 so thatapplication 112 may provide enrollment with SP 120. The handset maker(e.g., manufacturer of device 104) may provide this functionality, butit could also be provided by an operating system (OS) provider or aservice provider (such as SP 120 or a trusted service manager (TSM)).The enrollment process may include a number of various aspects thatallow for future risk management by SP 120. Many of the parametersneeded to create or allow the master token may be pre-determined (e.g.,at enrollment) and each SP can then use all or most of these “shared”parameters to be included into the generation of their sub-token. Theparameters pre-determined at enrollment may be used like a “checklist”or “shopping list” for preset parameters in the master token. When theuser makes a subsequent purchase, for example, a decision whether or notto require extra security could be triggered by parameters availablefrom the master token or sub-token and based on risk parameterspre-determined by the service provider.”

Application 114 may, for example, provide authentication for the user102 and device 104 by verifying the user's fingerprint (for example)when the user 102 subsequently logs in to device 104.

Merchant 130 may be a service provider (for example, a merchant site, anauction site, a marketplace, or a social networking site including P2Pmoney transfer or any other

P2P-like information transfer) offering various items such as productsor services through their website. Merchant 130 (which could be anyrepresentative or employee of the merchant) may process onlinetransactions from consumers making purchases through the merchant sitefrom mobile devices. Merchant 130 also may operate a merchant server 132capable of handling various on-line transactions automatically, forexample, by communicating over network 106 with client mobile device 104and service provider server 122. Merchant server 132 may run a purchaseapp 134 for offering products or services for purchase. Merchant server132 may also run a browser app 136 and other applications 138. Browserapp 136 and other applications 138 may enable the merchant to access aservice provider 120 web site and communicate with service providerserver 122; for example, to convey and receive information to allow aquick payment through the service provider 120. In accordance with oneor more embodiments, consumers (e.g., user 102) may access apps formaking transactions (e.g., payments) with a merchant 130 through aservice provider 120) without having to log in, which may enable quickerservice (e.g., completing payment processing) with service providerserver 132.

Service provider 120 may be an online payments provider, for example,providing processing for online financial and information transactionswith a merchant 130 on behalf of a user 102. Service provider server 122may include one or more identity apps 124, which may be adapted tointeract with the client mobile device 104 as well as merchant server132 over network 106 to facilitate the purchase of items, products, andservices by user 102. Service provider server 122 may be configured tomaintain multiple user and merchant accounts in an account database 126;each merchant account may include or be separate from accountinformation 128 associated with individual users, including user 102 andone or more merchants 130. For example, account information 128 mayinclude identity information of user 102 and merchants 130, such as oneor more full names, business names, street addresses, email addressesand phone numbers, website addresses, or other types of financialinformation, which may be used to facilitate online transactions betweenuser 102 and merchants 130. Account information 128 or identity app 124may also include device identifiers (e.g., unique device identifierpresent on the device, as described above, such as IMEI number) for userdevices such as mobile device 104. Thus, identity app 124 may beconfigured to interact with a merchant server 132, a user 102, mobiledevice 104, or other payee to process, obtain, and store information forallowing quick payments.

Email service provider 140 may provide email service for entitiesconnected to the network 106, such as merchant 130, service provider102, and individuals such as user 102. Email service provider 140 alsomay operate an email server 142 capable of providing email serviceautomatically, for example, by communicating over network 106 withclient mobile device 104, service provider server 122, merchant server132, and social networking server 152. Email server 142 may run an emailapp 144 for providing email service. Email server 142 may also run otherapplications 148.

Social networking service 150 may provide social network for individuals(and possibly other entities) connected to the network 106, such as user102. Social networking service 150 also may operate a server 152 onwhich may run a networking app 154, which could, for example, provide asocial networking website for access to various subscribers, such asuser 102, connected to network 106. Server 152 may also run otherapplications 158 for providing social networking services and websiteaccess.

FIG. 2 illustrates a mechanism 200 for score based fast login usingsub-tokens for login to multiple apps and communicating over a networkin accordance with one or more embodiments. As seen in FIG. 2, a user(e.g., user 102) may provide a biometric input 208 to a user device 104,which may be enabled for biometrics. For example, the user may swipe hisfingerprint on a mobile device having a fingerprint reading capability.Use of biometrics comprises a strong authentication of the user that canbe performed for unlocking the phone (instead of, for example, a PIN).

In response to the biometric input 208, a master token 201 may begenerated (at response 209) with some control parameters (e.g.,parameters for time, scope, field of applicability, settings). When themaster token 201 is generated using the parameters, a score may bederived that may be associated with the master token 201. For example,knowing the device ID, the user fingerprint read quality, the number oftimes the fingerprint has been recognized, the location (e.g., from GPS(geographical positioning system) on the device 104), and so forth, thequality of the master token may be higher or lower and could generate aquality score in the range of 0-100%. For example, an initial scorecould be 90%, but a bad read, unknown device, or an unusual locationcould, however, generate a master token 201 to which only a 40% score isattributed. Based on the score, various service providers via theirapplication (e.g., apps 224, 234, 244, 254) could decide if a login isrequired or can be bypassed. The score may be available on a sub-tokencorresponding to each app (e.g., sub-tokens 202, 203, 204, 205,respectively to apps 224, 234, 244, 254).

With the master token 201 and its associated score, a service provideror other entity (e.g., commercial entity 130, service provider 120,email service provider 140, social networking service 150) could allowtheir applications (e.g., commercial entity app 234, service providerapp 224, email service provider app 244, social networking app 254,respectively) running on the OS of the device (e.g., device 104) thathas been validated to leverage the authenticated (e.g., now known) userand the master token 201 to generate a sub-token to automatically launchsome of the functions in the apps flow based on the score or quality ofthe master token 201. The quality score associated to a master token 201may also allow processing in a manner that lightens the processing loadat the OS level and may speed up the login and sub-token generation.

The master token 201 may be stored on device 104 and may have provisionsfor linking it into a tree data structure 210, as shown in FIG. 2, whichmay also be stored in memory on device 104. The master token 201 may bestored in a trusted or secure area on device 104, for example, using atamper-resistant component, cryptographic protection, or other similarsecure technology. The tree data structure 210 and sub-tokens may besimilarly protected.

As shown in FIG. 2, master token 201 may be stored as a root token oftree 210 and subsequently generated sub-tokens (e.g., sub-tokens 202,203, 204, 205) may be linked to the master token 201 forming tree 210.As seen in FIG. 2, sub-tokens 202-205 appear as “leaves” but tree 210may also have intermediate, e.g., non-leaf, nodes in some embodiments.

As shown in FIG. 2, each sub-token may be created for a particular appon device 104 and may be used only by the app for which the sub-tokenhas been created. For example, sub-token 203 belongs to commercialentity app 234, running on device 104 and which may be used to interactwith commercial entity 130 by communicating with purchase app 134.Similarly, sub-token 202 belongs to financial service provider app 224,and so forth as seen in FIG. 2. Each sub-token may be created for itsparticular app by a service provider app (e.g., app 112 or app 114)which may be running on device 104 and which may be the same app whichgenerates the master token 201. Alternatively, each app may create itsown sub-token using permissions and access granted to the master token201. For example, app 234 may create sub-token 203, app 224 may createsub-token 202, app 244 may create sub-token 204, and app 254 may createsub-token 205. Creation of sub-tokens may be facilitated by the use ofan API for each app, e.g., apps 234, 224, 244, 254, including the“master” service provider app, e.g., apps 112, 114.

A sub-token may be endowed with special features such as countdown timer212 associated with sub-token 202 for financial service provider app224. In such an instance, it may be desirable for the “master” serviceprovider app, rather than the sub-token's own app, to create thesub-token to ensure that special features cannot overstep the boundariesprovided by the master token. For example, the countdown timer for thesub-token 202 would not be allowed to have a total time greater than theexpiration time for the master token 201, and that could be enforced byallowing only the “master” service provider app, e.g., apps 112, 114, tocreate sub-token 202 and not allowing the app 224 to create its ownsub-token. FIG. 3 illustrates a method 300 for score based fast loginusing sub-tokens for login to multiple apps and communicating over anetwork in accordance with one or more embodiments. At step 301 ofmethod 300, a user (e.g., user 102) may unlock a device (e.g., device104) using a strong form of authentication such as biometric technology.For example, the user may swipe a finger across a fingerprint reader tounlock the device, or may give a voice sample or other form of securityacceptable to a service provider (SP) resulting in strong binding of theuser with the device.

At step 302, an application master token (e.g., master token 201) may begenerated on the device with some control parameters (e.g., expirationtime, scope, field of applicability, settings for various parameters).At step 303, a score of the quality of the master token may be derivedfor the master token based on quality of various parameters, e.g.,device ID, the user fingerprint read quality, the number of times thisfingerprint has been recognized, the device location, and historicaldata kept by the SP, for example.

At step 304, when the user launches an app, the app may make a call (inthe background) to check for presence on the device of the master token,the score associated with the master token, and to find the master tokenand its quality score. Alternatively, these steps may be performed, asdescribed above by a “master” service provider app, e.g., enrollment app112 or authentication app 114.

At step 305, a sub-token (e.g., sub-token 202, 203, 204, 205) may becreated for the app (e.g., when the app is launched) with parameters inline with the SP risk policy (e.g., timed, expiration period, activemode period).

At step 306, when the user launches apps (e.g., any of apps 224, 234,244, 254), the user may be NOT asked to enter credentials (e.g., phonenumber and PIN or email and password) as the user has already beenverified if the quality score from the master token 201 is in line withthe policy developed and accepted by the SP. For example, financialservice provider app 224 may require a 99% score while social networkingapp 254 may require only an 80% score.

At step 307, the app may jump over the login process and go directly tovalidating a transaction. The transaction may be a purchase, in thecase, for example of shopping at merchant entity, e.g., using commercialentity app 234. Moreover, if a shopping checkout process using theservice provider 120 comes from another application (e.g., socialnetworking app 254) that has also been validated with a sub-token, theuser may just click to pay using the service provider 120 and, to verifythe amount, click for confirmation.

At step 308, different applications (e.g., apps 224, 234, 244, 254) mayhave sub-tokens (e.g., sub-tokens 202, 203, 204, 205, respectively) thatcan live (remain valid) for different lengths of time and for lengths oftime different than that for the master token 201. For example, a longertime may be allowed because of lesser security requirement or lessprivacy concerns from one app to another and such a decision could bebased on a lower score from the master token. For example, if the mastertoken 201 currently has a lower score than previously, apps may opt fortheir sub-tokens to remain valid for a shorter period of time to offseta greater perceived risk of the lower master token quality score.

At step 309, the master token can be revoked—for example, if there is adiscrepancy with a user biometric input versus the user biometricenrollment, the device has been off-grid for too long, or an update wasdone to an application. Revoking the master token can result incanceling or erasing all existing sub-tokens. When the user and thedevice are again strongly bound together (e.g., the user has logged backin to the device with a satisfactory biometric input 208), the mastertoken 201 may be generated and the sub-tokens reissued.

In implementation of the various embodiments, embodiments of theinvention may comprise a personal computing device, such as a personalcomputer, laptop, PDA, cellular phone or other personal computing orcommunication devices. The payment provider system may comprise anetwork computing device, such as a server or a plurality of servers,computers, or processors, combined to define a computer system ornetwork to provide the payment services provided by a payment providersystem.

In this regard, a computer system may include a bus or othercommunication mechanism for communicating information, whichinterconnects subsystems and components, such as a processing component(e.g., processor, micro-controller, digital signal processor (DSP),etc.), a system memory component (e.g., RAM), a static storage component(e.g., ROM), a disk drive component (e.g., magnetic or optical), anetwork interface component (e.g., modem or Ethernet card), a displaycomponent (e.g., CRT or LCD), an input component (e.g., keyboard orkeypad), and/or cursor control component (e.g., mouse or trackball). Inone embodiment, a disk drive component may comprise a database havingone or more disk drive components.

The computer system may perform specific operations by processor andexecuting one or more sequences of one or more instructions contained ina system memory component. Such instructions may be read into the systemmemory component from another computer readable medium, such as staticstorage component or disk drive component. In other embodiments,hard-wired circuitry may be used in place of or in combination withsoftware instructions to implement the invention.

Logic may be encoded in a computer readable and executable medium, whichmay refer to any medium that participates in providing instructions tothe processor for execution. Such a medium may take many forms,including but not limited to, non-volatile media, volatile media, andtransmission media. In one embodiment, the computer readable medium isnon-transitory. In various implementations, non-volatile media includesoptical or magnetic disks, such as disk drive component, volatile mediaincludes dynamic memory, such as system memory component, andtransmission media includes coaxial cables, copper wire, and fiberoptics, including wires that comprise bus. In one example, transmissionmedia may take the form of acoustic or light waves, such as thosegenerated during radio wave and infrared data communications.

Some common forms of computer readable and executable media include, forexample, floppy disk, flexible disk, hard disk, magnetic tape, any othermagnetic medium, CD-ROM, any other optical medium, punch cards, papertape, any other physical medium with patterns of holes, RAM, ROM,E2PROM, FLASH-EPROM, any other memory chip or cartridge, carrier wave,or any other medium from which a computer is adapted to read.

In various embodiments, execution of instruction sequences forpracticing the invention may be performed by a computer system. Invarious other embodiments, a plurality of computer systems coupled by acommunication link (e.g., LAN, WLAN, PTSN, or various other wired orwireless networks) may perform instruction sequences to practice theinvention in coordination with one another.

Modules described herein can be embodied in one or more computerreadable media or be in communication with one or more processors toexecute or process the steps described herein.

A computer system may transmit and receive messages, data, informationand instructions, including one or more programs (i.e., applicationcode) through a communication link and a communication interface.Received program code may be executed by a processor as received and/orstored in a disk drive component or some other non-volatile storagecomponent for execution.

Where applicable, various embodiments provided by the present disclosuremay be implemented using hardware, software, or combinations of hardwareand software. Also, where applicable, the various hardware componentsand/or software components set forth herein may be combined intocomposite components comprising software, hardware, and/or both withoutdeparting from the spirit of the present disclosure. Where applicable,the various hardware components and/or software components set forthherein may be separated into sub-components comprising software,hardware, or both without departing from the scope of the presentdisclosure. In addition, where applicable, it is contemplated thatsoftware components may be implemented as hardware components andvice-versa—for example, a virtual Secure Element (vSE) implementation ora logical hardware implementation.

Software, in accordance with the present disclosure, such as programcode and/or data, may be stored on one or more computer readable andexecutable mediums. It is also contemplated that software identifiedherein may be implemented using one or more general purpose or specificpurpose computers and/or computer systems, networked and/or otherwise.Where applicable, the ordering of various steps described herein may bechanged, combined into composite steps, and/or separated into sub-stepsto provide features described herein.

The foregoing disclosure is not intended to limit the present inventionto the precise forms or particular fields of use disclosed. It iscontemplated that various alternate embodiments and/or modifications tothe present invention, whether explicitly described or implied herein,are possible in light of the disclosure. Having thus described variousexample embodiments of the disclosure, persons of ordinary skill in theart will recognize that changes may be made in form and detail withoutdeparting from the scope of the invention. Thus, the invention islimited only by the claims.

What is claimed is:
 1. A user device configured to execute a pluralityof apps and communicate over a network with a service provider, the userdevice comprising: a user interface; a processor in communication withthe user interface; and a memory device having instructions that, whenexecuted by the processor, cause the user device to: receive anauthentication of a user by the service provider through a first app ofthe plurality of apps in response to an input from the user received viathe user interface; create, by the first app, a master token having aquality score based on the authentication; generate, based on thequality score, a sub-token of the master token associated uniquely witha second app of the plurality of apps; and authenticate the user for useof the second app using the sub-token.
 2. The user device of claim 1,further comprising: a biometric reader device; and instructions in thememory device that, when executed by the processor, cause the userdevice to: accept a biometric input from the user to the biometricreader device; derive a value of the quality score based on one or moreof a read quality of the biometric input and a number of times thebiometric input has been recognized; and determine whether a login isrequired based on the value of the quality score.
 3. The user device ofclaim 1, wherein: the sub-token associated uniquely with the second appcomprises a special feature that is enforced by the first app generatingthe sub-token and not allowing the second app to generate the sub-token.4. The user device of claim 1, wherein: the second app generates thesub-token associated uniquely with the second app, based on accessingthe master token and using permissions and access granted to the mastertoken.
 5. The user device of claim 1, further comprising instructionsthat, when executed by the processor, cause the user device to:determine based on the sub-token whether additional security is neededfor the user to access the second app; and authenticate the user for useof the second app using the sub-token based on the determination ofadditional security needed.
 6. The user device of claim 1, wherein: anapp of the plurality of apps that is not the second app cannot use thesub-token associated uniquely with the second app.
 7. The user device ofclaim 1, wherein: a service provider app of the plurality of appsgenerates a sub-token of the master token to automatically launch afunction of the service provider app flow based on the quality score ofthe master token.
 8. The user device of claim 1, wherein: the second appvalidates a transaction using the sub-token without executing a loginprocess for the second app.
 9. The user device of claim 1, wherein: aservice provider app of the plurality of apps allows the user to pay fora transaction based on a checkout process of the second app based on thesub-token associated uniquely with the second app.
 10. The user deviceof claim 1, wherein: the master token is stored in the memory device asa root token of a tree data structure; and the sub-token is stored inthe memory device and linked in the tree data structure to the roottoken.
 11. A method of authenticating a user of an application using asub-token of a master token, the method comprising: receiving anauthentication of a user through a first app of a plurality of appsinstalled on a user device, the authentication from a service providerin response to an input from the user received via a user interface ofthe user device; creating a master token with a quality score of themaster token based on the authentication; generating, based on thequality score, a sub-token of the master token belonging to a second appof the plurality of apps; determining a level of security of theauthentication for the user to access the second app based on thesub-token; and providing access to the user for the second app at thelevel of security.
 12. The method of claim 11, further comprising:accepting a biometric input from the user to a biometric reader deviceof the user device; deriving a value of the quality score based on thebiometric input; and determining the level of security based on thesub-token and the quality score.
 13. The method of claim 11, wherein thesub-token is generated by a master service provider app of the pluralityof apps.
 14. The method of claim 11, wherein the sub-token is generatedby the first app of the plurality of apps.
 15. The method of claim 11,wherein the sub-token is generated by the second app of the plurality ofapps.
 16. The method of claim 11, further comprising: generating thesub-token by a service provider app of the plurality of apps; andautomatically launching a function of the service provider app flowbased on the sub-token.
 17. The method of claim 11, further comprising:validating a transaction by the second app using the sub-token withoutexecuting a login process for the second app.
 18. The method of claim11, further comprising: allowing the user to pay for a transaction basedon the sub-token belonging to the second app and using a serviceprovider app of the plurality of apps in a checkout process of thesecond app.
 19. The method of claim 11, further comprising: accessingthe sub-token stored in a memory of the user device as a link from aroot in a tree data structure in which the master token is stored as theroot of the tree data structure.
 20. A non-transitory computer-readablemedium comprising instructions which, in response to execution by acomputer system, cause the computer system to: receive an authenticationof a user through a first app of a plurality of apps installed on a userdevice, the authentication sent from a service provider in response toan input from the user received via a user interface of the user device;create a master token with a quality score of the master token based onthe authentication; generate a sub-token based on the quality score ofthe master token, the sub-token belonging to a second app of theplurality of apps and having the same quality score as the master token;determining a level of security of the authentication for the user toaccess the second app based on the sub-token; and provide access to theuser for the second app based on the level of security.